02-# THE SOVEREIGN MAIL SYSTEM

Anglicised British-English Edition

Master Manuscript — PART 2

PART II — ARCHITECTURE

(Beginning of Part II, Chapters 4–6)

---

CHAPTER 4 — THE CONCEPT OF TECHNICAL SOVEREIGNTY

Sovereignty is usually a political word,
but in technology, it has a precise and powerful meaning:

Technical sovereignty is the ability to control your systems without requiring permission from vendors, hosting platforms, black-box interfaces, or unseen administrators.

This concept shaped your entire build.

Sovereignty means:

• You know how your system works.
• You choose the boundaries.
• You verify what others merely hope.
• You rebuild when others reinstall.
• You operate with clarity, not assumption.

1. Sovereignty Over Identity

Your system ensures that:

• your domains
• your DKIM keys
• your DNSSEC chain
• your TLS certificates
• your SNI blocks
• your mail transport
• your authentication paths

…are under your authority, not a provider’s.

Identity is the bedrock of email.
You own yours completely.

2. Sovereignty Over Infrastructure

Panels and cloud services hide:

• routing
• filtering
• mail queue behaviour
• authentication semantics
• DKIM alignment
• SPF enforcement
• DMARC decisions
• NAT traversal
• certificate chains
• TLS behaviour

You refused to accept this opacity.

Your system is transparent at every layer.

3. Sovereignty Over Risk

Sovereign systems survive:

• datacentre failure
• hardware loss
• DNS disasters
• certificate expiry
• misconfiguration
• malicious traffic
• ransomware
• ISP problems
• cloud provider collapse

Because resilience is built-in, not bolted on.

---

CHAPTER 5 — OVERVIEW OF THE ENTIRE SYSTEM

Before diving into each component, the reader must see the architecture from altitude.

Your system has six primary layers:

1. Hypervisor Layer – Proxmox PVE
2. Network & Firewall Layer – NAT, nftables, segmentation
3. Mail Gateway Layer – Proxmox Mail Gateway
4. Transport & Storage Layer – Postfix + Dovecot
5. Access Layer – IMAP/SMTP submission + Roundcube
6. Cryptographic Layer – DNSSEC, DANE, TLSA, DKIM, SPF, DMARC
7. Resilience Layer – Local PBS + Remote PBS

Each layer is separate, accountable, and inspectable.

Where others run a single server,
you operate an ecosystem.

1. The Roles of Each Layer

• PVE provides structure
• PMG provides protection
• Postfix provides movement
• Dovecot provides identity & storage
• DNSSEC provides truth
• DANE/TLSA provides authenticity
• PBS provides memory beyond hardware

This is layered design thinking at its finest.

2. Segmentation as a Design Philosophy

Segmentation gives you:

• security
• clarity
• resilience
• predictable behaviour

Isolation is the cornerstone of reliability.

By splitting PMG, Mailbox, Web services, and PBS into discrete VMs,
you ensured:

• no cross-pollution
• no shared attack surface
• no confusion of roles
• no dangerous interdependency

3. Identity as a First-Class Concept

Your architecture treats identity with the seriousness it deserves:

• per-domain TLS certificates
• per-domain DKIM
• per-domain Dovecot SNI
• per-domain DNSSEC anchouring
• per-domain DMARC alignment
• per-domain TLSA fingerprints

This is not shared hosting.
This is sovereign hosting.

---

CHAPTER 6 — PROXMOX PVE: THE HYPERVISOR FOUNDATION

Your entire infrastructure stands on PVE —
and PVE stands on open standards, transparency, and reproducibility.

1. Why PVE Was the Correct Choice

PVE gives you:

• full visibility
• full control over networking
• full isolation capabilities
• clean VM definitions
• stable clustering potential
• PBS integration
• firewall clarity
• SSH discipline
• snapshot-defined state

It does not hide anything.
It does not guess for you.
It does not rewrite your configurations.

It is a foundation worthy of sovereignty.

2. Virtual Machine Segmentation

Your VM structure embodies design discipline:

• PMG → Edge
• Mailbox VM → Postfix, Dovecot, Roundcube
• Web1 → Caddy + miscellaneous services
• PBS-local → Backup vault
• PBS-remote → Disaster vault
• Optional: application servers (Joplin, OpenProject, etc.)

Each VM has a purpose.
No VM has more purpose than it should.

3. Networking Inside PVE

You engineered:

• a WAN bridge
• a LAN bridge
• NAT boundaries
• hardened nftables
• isolation between VMs
• IPv6 disabled for safety
• SSH on port 47047
• DMZ-like protection around PMG

This network is not typical of small systems.
It is typical of properly designed systems.

4. Why PVE Enables Rebuildability

PVE’s VM definitions and PBS integration allow the crown jewel:

Your entire system can be restored from bare metal.

Most systems die when the hardware dies.
Yours does not.

---

END OF MANUSCRIPT PART 2